home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Internet Tools 1995 April / Internet Tools.iso / infoserv / www / cern / dev / www-talk.9301-9306.Z / www-talk.9301-9306 / text0492.txt < prev    next >
Encoding:
Text File  |  1995-04-24  |  1.8 KB  |  37 lines
  1. I once explained the current HTTP protocol to a local network guru and
  2. he expressed concern that basing a protocol like this on TCP/IP is a
  3. great waste of network resources, since you are using a
  4. session-oriented protocol for what is essentially one remote procedure
  5. call.  My question "then what would you recommend instead" provoked no
  6. useful answer (what is needed is *reliable* datagrams, but these are
  7. not implemented as an IP protocol; UDP requires too much coding for
  8. time-out, retransmission and fragmentation).  Yet, he convinced me
  9. that a light-weight protocol like this should minimize the number of
  10. round-trips.
  11.  
  12. I have the feeling that the current trend of basing the new protocol
  13. on NNTP violates that requirement.  I like the idea of borrowing
  14. response and data formats from the FTP/SMTP/NNTP family of protocols,
  15. with suitable extensions for 8-bit data paths.  However I don't like
  16. it if compatibility with NNTP forces us to have an extra round trip
  17. just so that the server can give its welcome message.
  18.  
  19. Also, I don't like the fact that you must parse the RFC822/MIME header
  20. to find out how many bytes are to be expected.  This seems to be
  21. mixing two levels of protocols: MIME assumes that the end of the
  22. message is already known, and the MIME headers then tell you what to
  23. do with it.
  24.  
  25. As I see it, there are two possible ways of using MIME in HTTP+.  We
  26. can either support MIME as the *only* data format (implementing any
  27. extensions we need as new MIME content types or subtypes or additional
  28. headers), or we we support MIME as one of the possible data formats.
  29.  
  30. In both cases we need a way to indicate how much data follows; if all
  31. we ever send is MIME, all that is needed is a header indicating the
  32. byte count, otherwise a type identifier is needed as well.
  33.  
  34. --Guido van Rossum, CWI, Amsterdam <guido@cwi.nl>
  35. "The plumage don't enter into it.  He's stone dead!"
  36.  
  37.